1. Field of the Invention
This invention relates generally to the field of network services. More particularly, the invention relates to an improved architecture for providing fault tolerant data communication.
2. Description of the Related Art
As is known in the art, streaming is a mechanism for playing back audio and/or video content over a network in-real-time, typically used in situations where network bandwidth is limited. The basic streaming concept is that the destination (e.g., a client) begins to play back the underlying streaming file from a buffer before the entire file has been received from its source.
A traditional network streaming system is illustrated in FIG. 1. As shown, one or more clients 150, 160, configured with streaming application software such as RealPlayer® from RealNetworks® or Windows Media® Player from Microsoft® Corporation, communicate with one or more streaming servers 110, 111, . . . N, over a network 100 (e.g., the Internet). The group of streaming servers 110, 111, . . . N, are located together at a point of presence (“POP”) site. Each of the streaming servers 110, 111, . . . N, may store a copy of the same streaming data or, alternatively, may store different streaming data, depending on the configuration at the POP site 130.
In operation, when a client 150 requests a particular streaming file from a server at the POP site 130, the request is received by a load balancer module 120, which routes the request to an appropriate streaming server 111. Which server is “appropriate” may depend on where the requested file is stored, the load on each server 110, 111, . . . N, and/or the type of streaming file requested by the client (e.g., Windows Media format or RealPlayer format). Once the file has been identified by the load balancer 120 on an appropriate server—server 111 in the illustrated example—it is streamed to the requesting client 150 (represented by stream 140) through the network 100.
One problem with current systems for streaming multimedia content, however, is that when delivery of a stream to a client/player 150 is interrupted, there is no automated mechanism for correcting the interruption (e.g., providing another source for the stream) without some type of manual intervention. For example, if server 111 in FIG. 1 were to crash while streaming content to client 150, the client's multimedia stream would be interrupted. The client 150 (or, rather, the streaming application) would then manually attempt to reconnect to the server 111 through the load balancer 120.
The problem is even more serious if the client 150 is receiving a stream of a live event or a scheduled event (e.g., such as a “Web-cast”). In this case, by the time the client 150 reestablished a connection, a significant portion of the event would simply be unavailable to the client 150. In sum, current streaming applications do not provide any mechanism for automatically and seamlessly reestablishing a streaming session with a client, once the initial session has been interrupted.
Accordingly, what is needed is a system and method for providing fault tolerance and/or automatic fail-over techniques with respect to streaming multimedia content over a network.